The use of the world wide web (WWW) is increasing rapidly, and so of course is the demand for intelligent systems and software which can permit users to better and more easily explore its offerings. To access information on the WWW, a user typically utilizes a browser program having a graphical interface (such as those offered by such companies as Sun, Microsoft, and Netscape) to establish an electronic connection between his/her local client computing system, and a remote server system located at an ISP (Internet Service Provider). After such connection is made, the user can then perform a number of operations through the browser, including such tasks as uploading/downloading files (including text, graphics, audio, video, etc.) and even executing programs located on such remote server. The ability to locally execute programs retrieved from a remote ISP is in fact one of the greater attractions and promises of the WWW. By having a repository which is accessible to millions of users simultaneously, program authors have an opportunity to expand the distribution and use of their products to a level far beyond that previously attainable. To avoid cluttering the user's local computing system with extraneous program and associated support files, and more importantly so as to provide a measure of protection and security to such user, many of such programs are now being implemented using a language known in the art as Java®, and, in particular, using programming tools known as “applets.” Java® applets are akin to Java® applications, but the former are specifically designed to interoperate with graphical user interfaces such as the conventional browsers mentioned above. Applets are extremely popular programs today also due to the fact that they provide program authors with the tools to create multi-media capable programs quickly and easily.
The ease of access to remote programs, however, also increases the possibility of potential security/privacy breaches at the user's local computing system. There is simply no practical method for a user to monitor the behavior of a remotely retrieved program to ensure that it is not improperly loading data to the user's system, or worse yet, capturing or altering private data from the user's local file system in his/her computing system. To address this concern, the authors of Java® intentionally constrained applets to operate in what is conventionally known as “sand box.” In other words, applets were imbued with substantial functionality, but they are not permitted, for example, to do such things as read or write from file systems outside their own domain (usually the file system of the remote server). So, in the case of a remotely downloaded applet embodying some code which the user desires to execute, such applet cannot read or write to the users local file system. For a discussion of this limitation of applets, please see “An Introduction to Computer Science—Using Java” by Kamin et. al., McGraw-Hill, p. 345 (1998). Another limitation, of course, is the fact that an applet cannot make use of data structures (such as graphics file formats for example) that are incompatible or unreadable with the browser within which such applet is executing.
Heretofore this limitation on applets has not posed a substantial barrier to the use of applet based programs on the WWW, although some attempts have been made to ameliorate the effects of this restriction. For example, some program designers have tried to exploit loopholes in the sandbox to trick the user's operating system into permitting the applet to gain local access and print a file on a local printer. These programming patches, however, are undesirable because they are system specific, and are susceptible to being closed down by Java® developers/standards enforcers. Others have suggested relaxing the constraints on applets which are known by the user to come from a verified “clean” source. By requiring an applet to pass through a certification process, some measure of security can be maintained. Again, nonetheless, such “exemption” process is also vulnerable to attack from would-be security invaders, and is therefore unattractive to users seeking the maximum security intended to be offered by the applet environment. It is also inconvenient to users, because they must still perform the task of evaluating whether a particular program is worthy of certification. This, too, reduces the incentives for users to use the WWW, since it requires too much effort for the ordinary user to know what is safe and what is unsafe.
Despite the fact that such efforts have been limited in the past, applicant has realized that the need for a satisfactory solution to the applet limitation is more crucial now. The inability of an applet to print to a local printer, for example, means that a local user is unable to capture his/her local input and/or contributions to an applet program displaying a remotely retrieved file. This limits the users enjoyment of the program, since any contributions are lost once the browser program is closed. For example, a user who has used an applet in his/her browser and accessed a stock price chart located on a remote server, can make annotations, mark-ups, etc., and see such contributions on a display screen. They cannot, however, print a hard copy of such image, and again this reduces significantly the user's enjoyment and the utility of such program.